System and method for safeguarding data between a device driver and a device

ABSTRACT

A data safeguarding system, method, and article for safeguarding an encrypted data-stream transmitting on a first channel from a first system to a second system. The data-stream can be intertwined with other data-streams. The data-stream is arranged in fixed length sequential blocks, each block including a header portion and a payload portion. The first system places a flag marking in the header portion indicating that the payload includes a tag having at least one identifier for selecting the decryption keys from the first system. The second system reads the flag, and if the flag indicates a tag portion, reads the tag portion. The second system transmits the identifier to the first system on a second channel. The first system reads the identifier, retrieves the keys, and transmits the decryption keys to the second system on the second channel. The second system receives the decryption keys and decrypts the data block using the decryption keys.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional application of U.S. patent applicationSer. No. 09/675,976, (Attorney Docket No. 042390.P7957), entitled“System And Method For Safeguarding Data Between A Device Driver And ADevice,” filed on Sep. 29, 2000 by Keith Shippy et al., assigned to acommon assignee, the entire subject matter which is herein incorporatedby reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to data encryption. More specifically, thepresent invention relates to safeguarding the transfer of data within adevice.

2. Background Information

With the proliferation of computers and networks, the amount andavailability of digitized data available for viewing and listening hasgrown. However, with this growth in the amount and availability ofinformation, content providers have desired greater protection of thedata from unauthorized use.

In order to protect data from unauthorized use, conventional dataprotection techniques, such as, for example, data encryption, have beenused to protect data as it is being transferred over a network orbetween devices. Content providers use a number of well known encryptiontechniques to encrypt sensitive data before transmission from onedevice, such as, for example, a satellite receiving dish, to a seconddevice, such as, for example, a computer or set-top box.

Different conventional types of encryption techniques are used dependingupon the source device of the data and the type of data bus being usedfor the transmission from one device to another. For example, datatransmitted from a Digital Video Disk (DVD) player to a computer usesContent Scrambling System (CSS) encryption, and data transmitted over anIEEE 1394 bus use Digital Transmission Content Protection (DTCP). Datatransmitted over other bus systems use a number of other encryptiontechniques. In order to decrypt the data as it is received, devices needto be able to decrypt data using the variety of techniques that are usedto encrypt the data. Thus, a device that receives both CSS and DTCPencrypted data needs to know the techniques for decrypting both types ofencrypted data.

The various encryption techniques employed only protect the data duringtransmission. Once the data is received, it must be decrypted in orderfor the receiving device to be able to process the data. Once the datais decrypted within the receiving device, the data is susceptible tounauthorized access and manipulation.

Moreover, these conventional systems do not protect the data inside anopen architecture device, such as a personal computer. Conventionalsystems do not control what applications access the incomingdata-stream, nor allow those applications to access the incoming datastream without being aware of the data originator outside the device.

SUMMARY OF THE INVENTION

According to one aspect of the invention, a machine readable mediumprovides instructions which when executed by at least one processor,cause the processor to perform operations. The operations includeencrypting a payload of a data-stream data block with at least one keybefore transmitting the data-stream from a first system to a secondsystem, replacing a portion of the payload with a tag that identifies atleast one decrypting key to the first system before transmitting thedata-stream from the first system to the second system, and setting aflag in a header of the data block that indicates that the payload hasthe tag before transmitting the data-stream from the first system to thesecond system.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described by way of exemplary embodiments,but not limitations, illustrated in the accompanying drawings. Identicalnumerals indicate the same elements throughout the figures.

FIG. 1 is one embodiment for a data safeguarding system block diagram;

FIG. 2 is one embodiment for an architecture of a data safeguardingsystem block diagram;

FIG. 3 is another embodiment for an architecture of a data safeguardingsystem block diagram;

FIG. 4 illustrates an exemplary architecture of a data safeguardingsystem, such as that shown in FIG. 2;

FIG. 5 is one embodiment for a protected content exchange (PCX) moduleof FIG. 2 block diagram;

FIG. 6 a is one embodiment for an encrypted data stream block diagram;

FIG. 6 b is one embodiment for a PCX replacement block diagram;

FIG. 7 is one embodiment for a shared buffer block diagram;

FIG. 8 is one embodiment for a PCX resync block block diagram;

FIG. 9 is a flow diagram of one embodiment for safeguarding protocolspecific data within a device;

FIG. 10 is a flow diagram of one embodiment for decrypting PCX encrypteddata by a decoding device;

FIG. 11 is a flow diagram of one embodiment for creating a PCX resyncblock;

FIG. 12 is a flow diagram of one embodiment for decrypting a PCX resyncblock;

FIG. 13 is one embodiment for an information synchronizing system blockdiagram.

FIG. 14 is one embodiment of a system block diagram showing thefunctional connection between a PCX module and an application decoderfor transferring a data-stream to a decoder application when they areseparate physical devices.

FIG. 15 is an exemplary computer system that is related to the use ofthe present invention, according to an embodiment.

FIG. 16 is one embodiment of a system block diagram showing thefunctional connection between a PCX module and an application decoderwhen they access a shared memory device.

FIG. 17 is one embodiment of a system block diagram of a shared memorydevice safeguarding system.

FIG. 18 is a flow diagram of one embodiment for transferring a singledata-stream and decryption keys to an application decoder.

DETAILED DESCRIPTION

In the following description, various aspects and details of the presentinvention will be described. However, it will be apparent to thoseskilled in the art that the present invention may be practiced with onlysome or all aspects of the present invention. For purposes ofexplanation, specific numbers, materials and configurations are setforth in order to provide a thorough understanding of the presentinvention. However, it will also be apparent to one skilled in the artthat the present invention may be practiced without the specific aspectsand details. In other instances, well known features are omitted orsimplified in order not to obscure the present invention.

Some portions of the descriptions that follow are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a circuit that can include a programmed computer system, orsimilar electronic computing device. A computer system manipulates andtransforms data represented as physical (electronic) quantities withinthe computer system's registers and memories into other data similarlyrepresented as physical quantities within the computer system memoriesor registers or other such information storage, transmission or displaydevices.

The present invention also relates to apparatus including circuits forperforming the operations herein. This apparatus may be speciallyconstructed for the required purposes, or it may include a generalpurpose computer selectively activated or reconfigured by a computerprogram stored in the computer. Such a computer program may be stored ina computer readable storage medium. A machine readable medium includesany mechanism that provides (i.e. stores and/or transmits) informationin a form readable by a machine such as a computer. For example, amachine readable medium includes, and is not limited to, read onlymemory (ROM); random access memory (RAM); magnetic disk storage media;optical storage media; flash memory devices; electrical, optical,acoustical or other form of propagated signals (such as carrier waves,infrared signals, digital signals, and so forth), or any type of mediasuitable for storing electronic instructions.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, the present invention is not described with reference toany particular programming language. It will be appreciated that avariety of programming languages may be used to implement the teachingsof the invention as described herein.

Various operations will be described as multiple discrete stepsperformed in turn in a manner that is most helpful in understanding thepresent invention, however, the order of description should not beconstrued as to imply that these operations are necessarily orderdependent, in particular, the order the steps are presented.Furthermore, the phrase “in one embodiment” will be used repeatedly,however the phrase does not necessarily refer to the same embodiment,although it may.

FIG. 1 is a block diagram of one embodiment for a data safeguardingsystem 100. Data safeguarding system 100 includes data safeguardingdevice 104, protocol specific input devices 110 and protocol specificbuses 120. Data safeguarding device 104 includes decoding devices 102,and a protected content exchange (PCX) module whose preferred embodimentincludes a memory 108, and a CPU 115 that executes programmedinstructions stored in a memory 108. PCX module 106 includes a number ofprotocol specific exchange modules 130.

Protocol specific encrypted data is received over protocol specific bus120 from protocol specific input devices 110. In the FIG. 1 example,encrypted data may be received over a 1394 DTCP bus from a number ofinput devices 110 such as a satellite dish or video recorder (VCR). Anyof a number of protocol specific buses 120 may be connected to datasafeguarding device 104 including, for example, a USB bus, a PCI bus,and a DVD bus. Once the encrypted data is received by data safeguardingdevice 104, CPU 115 directs the input to PCX module 106. Within PCXmodule 106, the appropriate protocol specific exchange module 130 isused to decrypt the encrypted input data stream. For example, if IEEE1394 DTCP bus encrypted data is received, a DTCP exchange module 130would be used to decrypt the input data. Input data is received and isdecrypted on a block-by-block basis.

Initially, PCX module 106 negotiates a content channel encryption keywith protocol specific input device 110. PCX module 106 then negotiatesa PCX session key with the client decoding device 102. Decoding device102 is the client that, in one embodiment, originally requested the datafrom device 110. Once the PCX session key is negotiated, PCX module 106re-encrypts the payload of the protocol specific data using a randomlygenerated PCX content key and transfers the re-encrypted data (includingheader and payload) to the appropriate decoding device 102. Oncedecoding device 102 receives the re-encrypted data, decoding device 102negotiates with the PCX module 106 to retrieve the PCX content keyencrypted by the PCX session key. Once the appropriate PCX content isretrieved, decoding device 102 decrypts the payload data. Decodingdevice 102 then manipulates the unencrypted data. In one embodiment,decoding device 102 decodes the unencrypted data. For example, if MPEGdata is requested by an MPEG decoder, the appropriate input device 110sends the data over the bus 120 to data safeguarding device 104. CPU 115executes the PCX module 106 which decrypts the MPEG input data streamusing a content channel encryption key for the bus 120. The MPEG decoderand PCX module 106 negotiate a PCX session key. The payload MPEG data isre-encrypted with the randomly generated PCX content key and there-encrypted data is sent to the MPEG decoder. PCX module 106 encryptsthe PCX content key with the PCX session key. The MPEG decoder retrievesthe encrypted PCX content key and decrypts the PCX content key with thePCX session key. In addition, the MPEG decoder uses the PCX content keyto decrypt the payload data for playback. The MPEG decoder thenretrieves the device key and decrypts the payload data for playback.

In one embodiment, data within system 100 is further protected fromtampering or from unauthorized access by the use of a number ofanti-tampering techniques such as, for example, self-modification of PCXmodule 106 code, the use of anti-debugging techniques, self-verificationof PCX module 106 code, signature verification of PCX module 106 code,and other applicable anti-tampering techniques. The use of theseanti-tampering techniques prevents unauthorized access or modificationof PCX module 106 code which prevents the unauthorized access ormodification of the data as it is being transferred through system 100.

FIG. 2 is a block diagram of one embodiment for an architecture of adata safeguarding system 100. Referring to FIG. 2, encrypted protocolspecific data is received over IEEE 1394 bus 220 and transferred to IEEE1394 bus driver 210. Bus driver 210 then sends the protocol specificdata to class driver 212. PCX module 106 intercepts the protocolspecific data and decrypts the data with a content channel encryptionkey. The content channel encryption key has originally been negotiatedbetween PCX module 106 and protocol specific input device 110 beforetransmission. Once the data is decrypted, PCX module 106 re-encryptsonly the MPEG portion of the payload of the data with a randomlygenerated PCX content key and encrypts the PCX content key with theappropriate PCX session key. This is repeated for the AC3 portion of thepayload with a different randomly generated key and a different PCXsession key. PCX module 106 sends the re-encrypted data back to classdriver 212. The re-encrypted data is transferred to a splitter 232 whichsplits the data between the various decoding devices. In the FIG. 2example, the splitter 232 splits the IEEE 1394 re-encrypted data to AC3device 216 and MPEG device 218. MPEG decoder 218 and AC3 decoder 216receive the appropriate encrypted PCX content key. MPEG decoder 218 andAC3 decoder 216 decrypt their PCX content key with their PCX sessionkey. MPEG device 218 and AC3 device 216 then decrypt the re-encrypteddata for playback using the appropriate PCX content key.

Thus, the data is protected from unwarranted hacking or copying withindata safeguarding system 100. Within data safeguarding system 100, thetransmission headers of the data are left decrypted while the payload ofthe data is re-encrypted by PCX module 106. Thus, the payload of thedata is protected from unwarranted copying or hacking during transferwithin system 100 while allowing untrusted components to access theportions of the data stream they need.

FIG. 3 is a block diagram of another embodiment of an architecture of adata safeguarding system 100. Referring to FIG. 3, protocol specificinput device 110 initially negotiates a content channel encryption keywith protocol specific registration engine 326. Protocol specific inputdevice 110 transmits the encrypted protocol specific data via protocolspecific bus 120 to bus driver 312. Bus driver 312 transfers theencrypted protocol specific data to device specific mini port driver 316via protocol specific class driver 314. Protocol specific bus abstractor320 abstracts the encrypted protocol specific data from device specificmini port driver 316. The extracted encrypted data is transferred to PCXmodule 106. Within PCX module 106, the encrypted protocol specific datais decrypted using protocol specific decryptor 322. Protocol specificdecryptor 322 decrypts the protocol specific data one block at a time.Each block of data contains a transmission header portion and a payload.In one embodiment, both the transmission header and payload portions areencrypted during transmission from source device 110 to datasafeguarding system 100. In an alternate embodiment, only the payloadmay be encrypted. Depending on the specific data bus transmissionprotocol being used, protocol specific decryptor 322 decrypts either theentire data block or the payload only.

Each data bus transmission protocol requires a corresponding protocolspecific decryptor 322. PCX negotiator 328 negotiates a PCX session keywith the decoding device 102 that is the intended recipient of theprotocol specific data. Once a session key is negotiated, protectedcontent exchange (PCX) encryptor 324 re-encrypts the payload portion ofthe data with a randomly generated PCX content key to producere-encrypted data. PCX encryptor 324 transfers the re-encrypted data toprotocol specific bus abstractor 320 which, in turn, transfers there-encrypted data to device specific mini port driver 316. Devicespecific mini port driver 316 sends the PCX re-encrypted data to theupstream drivers and libraries 330 which in turn transfers the PCXre-encrypted data to splitter 232.

Splitter 232 reads the transmission header of each re-encrypted datablock and transfers the data block to the decoding device 102corresponding to the information contained within the transmissionheader. In addition, in one embodiment, splitter 232 removes thetransmission headers from the data block. Within the data, data blocksare intermingled so that a variety of data blocks are received bysplitter 232. Thus, a video block may be received, then an audio block,then another video block, and so forth. The splitter transfers thepayload sections of the blocks to the corresponding decoding device asindicated by the transmission header. Once the re-encrypted payload datais received by a decoding device 102, decoding device 102 retrieves theencrypted PCX content key from PCX negotiator 328. Decoding device 102decrypts the content key using its PCX session key which was originallynegotiated with PCX negotiator 328. The unencrypted data is thenconsumed by decoding device 102.

FIG. 4 illustrates an exemplary architecture of safeguarding system 100.Referring to FIG. 4, protocol specific input device 110, such as a VCR,negotiates with a playback device such as MPEG decoder 435 to transmit astream of encrypted data to MPEG decoder 435. Protocol specific inputdevice 110 initiates the transmission of a stream of encrypted protocolspecific data marked with the appropriate copy protection status (i.e.,“copy-1-generation,” “copy-never,” or “no-more-copies”). The copyprotection status is transmitted via the encryption mode indicator (EMI)bits within the transmission header of the data. If data requested bydecoding device 102 (such as an MPEG decoder 435) is copy protected,protocol specific input device 110 may choose to transmit an empty datastream until at least one decoding device 102 has completed theappropriate authentication procedure required to access the contentstream. Within data safeguarding system 100, protocol specific inputdevice 110 negotiates authentication through PCX negotiator 328 and notdirectly with protocol specific input device 110. In the FIG. 4 example,VCR 110 negotiates authentication with DTCP registration engine 426.Once protocol specific input device (VCR) 110 and DTCP registrationengine 426 have completed the required AKE procedure, a content channelencryption key may be exchanged between protocol specific input device110 and DTCP registration engine 426. This content channel encryptionkey is used to encrypt the data by protocol specific input device 110and decrypt the IEEE 1394 encrypted data by DTCP decryptor 422.

Once the content channel encryption key is negotiated, IEEE 1394encrypted data is transferred from protocol specific input device 110via IEEE 1394 bus driver 210, to class driver 212 and eventually todevice specific mini port driver 416. DTCP bus abstractor 420 abstractsthe IEEE 1394 encrypted data from device specific mini port driver 416and transfers the IEEE 1394 encrypted data to PCX module 106. The IEEE1394 encrypted data is decrypted by DTCP decryptor 422 one block at atime using the content channel encryption key previously negotiated byDTCP registration engine 426. In the IEEE 1394 example, both thetransmission headers and the payload are encrypted by protocol specificinput device 110. Thus, DTCP decryptor 422 decrypts both thetransmission header and payload portions of the IEEE 1394 encrypted datablock.

If video decoder 438 has not previously registered with PCX module 106,PCX negotiator 428 authenticates video decoder 438. Duringauthentication, video decoder 438 is registered with PCX negotiator 428and video decoder 438 negotiates a key exchange with PCX negotiator 428.The key exchange method between video decoder 438 and PCX negotiator 428is similar to the key exchange method between decoding device 110 andDTCP registration engine 426 described above. Once a session key isnegotiated between video decoder 438 and PCX negotiator 428, PCXencryptor 424 encrypts the payload of the data blocks using a randomlygenerated PCX content key. The re-encrypted IEEE 1394 data blocks aretransferred to DTCP bus abstracter 420 for transfer to device specificmini port driver 416. The re-encrypted IEEE 1394 data is transferred viaWDM stream class driver 430 and WDM streaming library 432 to sourcefilter 434. At source filter 434, re-encrypted IEEE 1394 data intendedfor MPEG decoder 435 is split off from the other IEEE 1394 data andtransferred to MPEG decoder 435. The re-encrypted IEEE 1394 data ismuxed as MPEG transport stream (TS) to MPEG TS splitter 436. MPEG TSsplitter 436 splits the video and audio portions of the MPEG TS andremoves the transmission headers. The video portion of the TS istransferred to video decoder 438. Video decoder 438 requests the PCXcontent key from PCX negotiator 428. PCX negotiator 428 encrypts the PCXcontent key with the appropriate PCX session key and transfers it tovideo decoder 438. Video decoder 438 decrypts the PCX content key usingthe previously negotiated PCX session key and used the content key todecrypt the video data. In addition, the video decoder 438 consumes thedata. In a similar manner, audio decoder 440 receives the audio TS anddecodes the audio TS with a device key retrieved from PCX negotiator428.

In standard MPEG video, the audio and video blocks are interwoventogether within the input data stream. In order to separate the data,the MPEG splitter 436 reads the transport stream headers. Within datasafeguarding system 100, MPEG decoder 435 only needs to use the PCXspecific protocols in order to interact with PCX negotiator 428 and doesnot need to be able to use each individual data bus transmissionprotocol. PCX module 106 is able to translate the encrypted protocolspecific data from any specific bus into PCX encrypted data that theMPEG decoder 435 is able to understand and decode. Thus, there-encryption of the protocol specific data by PCX module 106 isindependent of any specific bus protocol used by system 100. Decodingdevices 102 are independent of the command protocol of the specific bus.The bus abstractor 420 abstracts the DTCP status structure, encapsulatesthe status structure in the proper command protocol, and transmits theencapsulated protocols to the driver 416 and vice versa. In this manner,decoding devices 102 are capable of receiving encrypted data from anyprotocol specific bus 120 without negotiating the content channelencryption key with the input devices 110 or knowing the encryptionprotocol for the specific buses 120. As existing bus protocols changeand new bus protocols are developed, PCX module 106 may be updated.However, decoding devices 102 only need to be able to talk with PCXmodule 106 and only need to be updated when the PCX module 106negotiation protocols are updated.

PCX module 106 may be implemented in software or hardware. The PCXmodule 106 may be incorporated within RAM memory of a personal computeror may be contained within flash memory which is attached to a CPU orother data processing device. Thus, PCX module 106 is easily updatedindependent of decoding devices 102.

FIG. 5 is a block diagram of one embodiment for a protected contentexchange (PCX module 106). Referring to FIG. 5, PCX module 106 containsprotocol specific decryption modules 500, PCX encryption modules 510,protocol specific registration modules 520, and PCX negotiation modules530. A protocol specific decryption module 500 may be maintained foreach protocol specific bus connected to data safeguarding system 100.Thus, PCX module 106 may contain decryption module 1 (502) throughdecryption module n (504). PCX module 106 may contain a number of PCXencryption modules 510. Thus, PCX module 106 may contain PCX encryptionmodule 1 (512) through PCX encryption module n (514) for the encryptionof a number of devices. In an alternate embodiment, only one PCXencryption module 510 may be maintained.

PCX module 106 includes a number of registration modules 520 for thenegotiation of content channel encryption keys with protocol specificinput devices 110. In one embodiment, PCX module 106 may containregistration module 1 (522) through registration module n (524)corresponding to each protocol specific bus connected to the system.

PCX module 106 contains PCX negotiation modules 530 which are utilizedby data safeguarding system 100 to negotiate key exchanges with decodingdevices 102. In addition, the negotiation modules authenticate thedecoding devices and maintain key synchronization between PCX module 106and decoding devices 102. In one embodiment, PCX module 106 includesfrom negotiation module 1 (532) through negotiation module n (534)corresponding to individual decoding device 102.

FIG. 6A is a block diagram of one embodiment of an encrypted data stream600. Referring to FIG. 6A, encrypted data stream 600 contains a numberof blocks of data, each block containing a transport header 602 and apayload 604. In one embodiment, the payload 604 and the transport streamheader 602 may be 188 bytes in length. Within the encrypted data stream600, each block of data may be for a different device 102. For example,MPEG audio and video data may be interleaved within encrypted datastreams 600. In addition, MPEG audio and video data may be interleavedwith AC3 and other data.

Referring now to FIG. 6B, in an embodiment of the present invention aPCX data block 606 sent from a PCX module 106 to an application decoder102 includes both a header 608 portion and a payload 616 portion. Theheader 608 portion is generally conventional and includes conventionalblock characteristic information, and a flag 609 of the presentinvention that indicates whether the payload 616 of the block datacontains a tag 610, or alternatively whether the payload contains a PCXencrypted data. In one embodiment, the header 608 is a packetizedelementary stream (PES) header. The payload 616 portion of the presentinvention includes the tag 610 at a predetermined position that includesan identifier information that can be sent to the PCX module foraccessing the decryption key(s) for the payload as well as preferably aportion of the payload replaced by the tag, disclosed presently. The tagpreferably includes a stream identifier datum 612 for distinctlyidentifying the data stream, and a source datum 614 for distinctlyidentifying the stream source, enabling the application decoder 102 totransmit to a PCX module a message that requests the decryption keys andpreferably the portion of the payload for the identified data-streamfrom a PCX module that can access the decryption keys and preferablyportion of the payload. In a safeguarding system 104 in which adata-stream identifier unambiguously includes the data sufficient toaccess the decryption keys and preferably the portion of the payload,the tag should only include the data-stream identifier. In othersystems, particularly those have a plural number of PCX modules, the tagshould also include an additional datum such as the source datum 614.When the payload includes the tag 610, the encrypted data stream ismodified to replace a portion of the payload that is the size of thetag, with the tag. Thus, the payload content data 616 of the presentinvention is an encrypted form of the conventional data block that has asmaller portion replaced by the tag 610. This shall be presented more insubsequent paragraphs with reference to FIGS. 14 and 17.

Referring now to FIG. 14, the block diagram depicted includes the PCXmodule 106, and the decoders 102, that contain circuitry of the presentinvention. The preferred embodiment of the application decoder 102 andthe PCX module 106 each include a processing unit that responds toprogram instructions of the present invention. Alternatively, as is wellknown to practitioners of the art, the circuitry does not require aprocessing unit and can be implemented as a fixed digital circuitwithout the configurable circuit advantages provided by a programmedprocessing unit.

The source device 110 transmits an exemplary two intertwineddata-streams, a video data-stream and an audio data-stream, to a devicespecific driver stack 1410 of data safeguarding device 104 via a bus1420 a. Each data-stream includes a sequence of data blocks, each datablock having a conventional header and payload. The driver stack 1410retransmits each data-stream to an appropriate PCX module 106. The PCXmodule 106 includes at least one decryptor and protocol specificregistration engine, and at least one PCX encryptor and PCX negotiator,described herein with reference to FIGS. 3 and 4. Each data-streamtransmitted from the source device 110 is optionally encrypted. Thedata-stream payloads are each encrypted by a PCX module 106 beforetransmission to an application decoder 102, or alternatively optionallyencrypted by a PCX module 106 if an individual data stream wastransmitted from a source device 110 encrypted, and subsequentlydecrypted, by the PCX module 106, so as to distinctly encrypt the datawithin the data safeguarding device 104.

The embodiment portrayed in FIG. 14 includes an application decoders 102a and 102 b that are each a physically separate device from the PCXmodule 106. There are two separate data transmission channels connectingthe PCX module 106 to each physically separate application decoder 102 aand 102 b. One of the separate data transmission channels transmits thedata-stream from the PCX module 106 to the application decoder. Theother separate data transmission channel transmits the non-data-streamdata between the PCX module 106 and an application decoder 102, so thesetransmissions do not impact other components that access the data-streamtransmission. In the embodiment portrayed in FIG. 14, each channel is aseparate physical transmission line.

The data-stream data transmission path includes the PCX module 106 thatsends the exemplary intertwined data-stream to a driver stack 1410. Thedriver stack 1410 sends the data-stream to a splitter 1432, wherein eachseparate data-stream is then separated and separately transmitted to anappropriate exemplary application decoder 102 a or 102 b. The videodata-stream is routed to the exemplary video application decoder 102 a,and the exemplary audio data-stream is routed to the exemplary audioapplication decoder 102 b. The non-data-stream data transmission pathbetween the PCX module 106 and the decoder 102 a is exemplary bus 1460a, and between the PCX module 106 and the decoder 102 b is exemplary bus1460 b, wherein buses 1460 a and 1460 b may be identical physicaldevices. The non-data-stream data includes the identifier necessary forthe PCX module to access the data block decryptor keys and optionalportion of the payload. The non-data-stream data preferably includes adata-stream identification datum and a source identification datum fromthe decoders 102 a and 102 b, and the encryption keys and the portion ofa replaced payload from the PCX module 106. The preferred embodimentnon-data-stream data additionally includes an authentication and keyexchange (AKE) from the PCX module 106 to the exemplary applicationdecoders 102 a and 102 b to enable a separately encrypted tag and theaforementioned encryption keys to be themselves encrypted, assuring theembodiment of an authorized and secure decoder(s) 102 in communicationwith the PCX 106 module and receiving the data-stream. The precisemethod of transmitting and receiving the data-streams, datumidentifiers, and encryption keys, shall be described with reference toFIG. 17.

Referring now to FIG. 15, a programmed processor embodiment of the PCXmodule 106 runs on a computer system that can include an exemplaryunitary processor 1510 that processes data signals. The processor 1510may be a complex instruction set computer (CISC) microprocessor, areduced instruction set computing (RISC) microprocessor, a very longinstruction word (VLIW) microprocessor, a processor implementing acombination of instruction sets, or other processor device. However, itis understood that the present invention may be implemented in acomputer system having multiple processors. The processor 1510 iscoupled to a CPU bus 1520, or other communication device forcommunicating information, that transmits data signals between processor1510 and other components in the PCX module 106. The computer systemincludes a memory 1530, or other computer readable media that iscommonly a random access memory (RAM) device or other dynamic storagedevice, that can be used to store temporary variables or otherintermediate information during execution of instructions by processor1510, and is coupled to the bus 1520. The PCX module 106 also includes aread only non-volatile memory such as a semiconductor Read Only Memory(ROM) device, and/or other static storage device 1540 coupled to bus1520 for storing static information and instructions for processor 1510.Data storage device 1550 is another computer readable medium coupled tobus 1520 for storing information and instructions, and can be suchexemplary computer readable media as magnetic disk, and/or an opticaldisk and corresponding drives. Display 1560 is coupled to bus 1520 fordisplaying data generated by the processor 1510, and mouse 1570, orother exemplary selecting or pointing device, and keyboard 1580, eachcouple to the bus 1520.

Referring to FIG. 16, a PCX module 106 includes a programmed processingdevice 1605 that accesses a memory unit 1615 for transmission of theencrypted data stream to that memory unit 1615, and for transmission ofthe keys(s) and tag data. The system includes the exemplary applicationdecoders 1610, embodied by an exemplary video data application decoder1610 a and an exemplary audio data application decoder 1610 b. Theapplication decoders 1610 each access the memory unit 1615 for theencrypted data stream. The tag data is read by the decoders 1610, andsent back to the memory unit 1615, for access by the PCX computingdevice 1605, and a placement of the relevant key(s) and portion of thepayload into a memory location that a decoder 1610 a or 1610 b accessesfor a read of the key(s) and the replaced portion of payload data.Alternatively, the PCX computing device 1605 can store the key(s) andpayload portion in the memory unit for a direct read by an applicationdecoder 1610 according to the content of the transmitted tag data. Inanother embodiment, as disclosed herein, the application decoder(s) 1610and the PCX computing device can be embodied by a unitary computingdevice that executes both program instructions for the applicationdecoder(s), and the PCX module.

Referring to FIG. 17, a preferred embodiment block diagram depictedincludes the PCX module 1706, the decoders 1702, and the driver stack1710 that contain circuitry of the present invention. As formerlydescribed with reference to FIG. 14, the source device 1110 transmits anexemplary two intertwined data-streams to a device specific driver stack1710 of data safeguarding device 104 via a bus 1420 a. The datasafeguarding device 104 includes a shared memory 1715. The driver stack1710 moves each block to memory 1715 where it is written into a buffer1715 a of the memory 1715, and sends to the PCX module 1706 a pointer tothe buffer 1715 a for each block. The PCX module 1706 accesses eachblock according to its memory pointer and distinctly encrypts the datawithin the safeguarding device 104 as described with reference to FIG.14.

The PCX module 1706 additionally replaces a portion of the payload withthe tag, and marks a flag, as described with reference to FIGS. 6 b and14, and as will be described with reference to FIG. 18. The memory 1715includes a second buffer 1715 b that both the exemplary decoders 1702 aand 1702 b and the PCX module 1706 write to and read from fortransmission between them of non-data stream data described withreference to FIG. 14, and FIG. 18. The PCX module may also include asplitter circuit that places a pointer in the buffer 1715 b identifyingto the application decoders 1702 the data-streams directed to eachseparate exemplary application 1702 a and 1702 b, ort alternativelytransmit that data over a separate physical line directly to theapplication decoders 1702 in a configuration that includes apre-existing physical bus as depicted with reference to FIG. 14. Thesplitter circuit may be physically separate form the PCX module 1706including a separate processor that may receive pointers directly fromthe driver stack 1710, and may write into a separate buffer in thememory 1710. In the embodiment herein portrayed. The interface between adecoder 1702 a and 1702 b and the buffer 1715 a is a first channel, andthe interface between a decoder 1702 a and 1702 b and the buffer 1715 bis a second channel.

Referring now to FIG. 18, the method and circuit herein describedapplies to a system of a decoding application 102, portrayed withreference to both FIG. 14, wherein an exemplary video decoder 102 a andaudio decoder 102 b, and a physically separate PCX module 106, in whicha data stream is sent to the PCX module from a source device 110; andanalogously to FIG. 17 as an exemplary video decoder 1702 a and audiodecoder 17102 b, and a physically separate PCX module 1706; as well as asystem implemented by a processing device that is both a PCX module andan application decoder(s). As has been described with reference to FIG.14, the preferred circuit includes a programmed processing device, butalternatively can be implemented by digital circuitry that does notinclude a programmed processing device, or can be implementedalternatively by a programmed processing device in at least oneapplication decoder and/or the PCX module, or a processing device thatis embodied partially, but not completely, by a programmed processingdevice.

The data stream transmitted to the safeguarding system is alternativelyunencrypted, or encrypted and has been decrypted by the PCX module asdescribed herein. At block 1805, the PCX module not necessarily butpreferably performs an AKE procedure with each decoder to create ashared session key with each decoder. This session key will be used toencrypt the decryption keys before they are sent back to the decoder.Additionally this AKE will assure that the applications are authorizedto access the PCX module encryption system. At block 1810, the PCXmodule encrypts the data block payload. The payload is encrypted usingat least one key. At block 1815, the PCX source module stores atag-sized portion of the encrypted payload for subsequent transmissionto an application decoder. In the preferred embodiment, the entirepayload is encrypted using the key(s). In the present invention, thestored portion can alternatively be encrypted separately with thekey(s), or can be optionally left unencrypted. The payload in afollowing block shall be decrypted in accordance with the encryptioncharacteristic of the stored portion.

At block 1820, a tag is inserted into the payload in the place of thesaved payload portion. The tag includes in the preferred embodiment bothan identification of the data stream 612 and an identification of thedata stream source 614, the source identified because a safeguardingsystem may include more than one source circuit. The encryption keys andthe saved portion of the payload are each referenced to the data-streamidentifier. At block 1825, a flag in the header is marked to indicatethat the block contains a payload tag. At block 1830, the data block issent to the appropriate decoder 102 along the data-stream transmissionchannel described with reference to FIG. 14, or alternatively describedwith reference to FIG. 17. At block 1835, the appropriate applicationdecoder has received the data block from the splitter 1432 withreference to FIG. 14. At block 1840 the application decoder that hasreceived the data block reads the header flag position and at block 1845determines whether the header flag is marked. If the header flagindicates that the payload does not contain a marked flag, controlpasses out of this flow. If the header flag indicates that the payloaddoes contain a tag, control passes to block 1850 where the data streamidentifier datum and the source datum are read and an identifier of eachis sent back to each PCX module or alternatively, only the data streamidentifier is sent back to the source module circuit identified by thesource datum. In the embodiment in which the application decoder module,and the PCX module are physically separate devices, the identifier(s)are sent back to the PCX module along the separate channel as hereindescribed.

At block 1855 the appropriate PCX module reads the data streamidentifier. The proper application keys and portion of the payload aredetermined by reference to the data stream identifier. The second set ofencryption key(s) and the stored portion of the payload that wasreplaced by the tag are transmitted to the target application decoder inaccordance with the data stream identifier. In the embodiment in whichthe application decoder module and the PCX module are physicallyseparate devices, the identifiers are sent back to the PCX module alongthe separate channel as herein described. At block 1860, the appropriateapplication decoder receives the decryption keys key(s) and the payloadportion transmitted from the PCX module at block 1855, and decrypts thekey(s) with the session key, replaces the payload portion from the tagposition, and then decrypts the payload using the decrypted key(s).

FIG. 7 is a block diagram of one embodiment for a shared buffer 700.Shared buffer 700 includes a device specific header 710 and PCX resyncblocks 720. Device specific header 710 includes a header data portion712 and PCX content key 714. In one embodiment, PCX resync blocks 720contain from PCX resync block 1 (722) through PCX resync block n (726).Header data 712 identifies the decoding device 102 corresponding to theshared buffer 700. In one embodiment, each decoding device 102corresponds to a unique shared buffer 700. In an alternate embodiment,all decoding device 102 use a single, shared buffer 700. Shared buffer700 may be any applicable data structure such as, for example, an array,linked list, or other applicable data structure. PCX content key 714 isencrypted with the previously negotiated PCX session key and is the keythat will be used to decrypt the payload.

FIG. 8 is a block diagram of one embodiment for PCX resync block 720.Referring to FIG. 8, PCX resync block 720 includes key delta tag 810,random initialization vector 815, and portion of the encrypted payloaddata 820. PCX resync block 720 is utilized for key synchronization asdescribed below.

FIG. 9 is a flow diagram of one embodiment for safeguarding protocolspecific data within a device. Initially at processing block 905, datasafeguarding system 100 receives encrypted protocol specific data. Theencrypted protocol specific data may be encrypted for any of a varietyof data bus security protocols such as, but not limited to DigitalTransmission Content Protection (DTCP), Content Scramble Systems (CSS),and Content Protection for Recordable Media (CPRM). The protocolspecific data is received in processing blocks one block at a time.

At processing block 910, the encrypted protocol specific data istranslated into protected content exchange (PCX) re-encrypted data. Thetranslation of the data includes decrypting the encrypted protocolspecific data using a content channel encryption key to producedecrypted data. Once the data is decrypted, the payload of the decrypteddata is re-encrypted using a PCX content key to produce PCX re-encrypteddata. The content channel encryption key is negotiated by a protocolspecific registration engine 326 with protocol specific input device 110upon initiation of the transfer of protocol specific data from theprotocol specific input device 110 to decoding device 102. Once protocolspecific input device 110 and protocol specific registration engine 326have completed the required AKE procedure, a content channel encryptionkey may be exchanged between protocol specific input device 110 andprotocol specific registration engine 326. This content channelencryption key is used to encrypt the data by protocol specific inputdevice 110 and decrypt the encrypted protocol specific data by protocolspecific decryptor 322. The session key is negotiated between PCXnegotiator 328 and decoding device 102.

After the data is re-encrypted, the re-encrypted data and the PCXcontent key encrypted by the PCX session key are transferred to thedecoding device 102 at processing block 915. In one embodiment, there-encrypted data is split into a number of data streams which aretransferred to appropriate decoding devices 102. At processing block920, decoding device 102 decrypts the PCX content key and uses it todecrypt the re-encrypted data. The unencrypted data is further decodedby decoding device 102.

FIG. 10 is a flow diagram of one embodiment for decrypting re-encrypteddata by decoding device 102. Referring to FIG. 10, decoding device 102receives re-encrypted data at processing block 1005. At processing block1010, decoding device 102 retrieves the encrypted PCX content key fromPCX negotiator 328. If decoding device 102 is not registered, PCXnegotiator 328 registers the protocol device 102 and negotiates the PCXsession key for the protocol device 102. At processing block 1015,decoding device 102 decrypts the re-encrypted data using the PCX contentkey.

FIG. 11 is a flow diagram of one embodiment for creating a PCX resyncblock 720. Initially at processing block 1105, PCX module 106 receivesprotocol specific encrypted data. Next, at processing block 1110, PCXmodule 106 determines if a new resync point has been reached. If a newresync point has not been reached, processing continues at processingblock 1130. If a new resync block has been reached, processing continuesat block 1111. At processing block 1111, PCX module 106 determines ifPCX content key needs to be generated. If no new PCX content key needsto be generated, processing continues at processing block 1115. However,if a new PCX content key needs to be generated, processing continues atprocessing block 1112.

At processing block 1112, the new PCX content key is generated. PCXmodule 106 uses the existence of natural synchronization points withinthe original data stream to determine when to create a new PCX contentkey.

At processing block 1115, PCX module 106 generates PCX tag 610 that is aunique identification for the PCX resync block 720. In one embodiment,PCX tag 610 may be an array index value. In alternate embodiments, PCXtag 610 may be any suitable index value to the PCX resync block 720. Atprocessing block 1120, PCX module 106 copies PCX flag 609, PCX tag 610,TSID 612, and PID 614 into the payload portion of the data stream andsaves the original portion in location 820 in the resync block 720.

At processing block 1125, PCX module 106 updates PCX resync data 720. Ifthe PCX content key being used to encrypt the payload is different fromthe PCX content key used on the previous block for the same decodingdevice 102, key delta tag 810 is incremented. Otherwise, key delta tag810 is unchanged. In this manner, PCX content keys may be changedperiodically during re-encryption of the data. This increases thesecurity of the data within system 100. In one embodiment, PCX contentkey is changed on a fixed time interval or after a fixed number of PESheaders 608 have been processed.

In order to increase the security of system 100, the PCX content key isaltered on each PES header 608 change by using a random initializationvector as a seed value to modify the key. This allows splitter 232 todrop a data block without losing the ability to decrypt the remainingdata in the input stream. In one embodiment, key delta tag 810 andrandom initialization vector 815 are not encrypted. PCX content key 714is encrypted with the previously negotiated PCX session key.

At processing block 1130, PCX module 106 encrypts the payload containingthe resync data using the PCX content key.

FIG. 12 is a flow diagram of one embodiment for decrypting a PCX resyncblock 720. Initially at processing block 1205, decoding device 102receives a block of PCX encrypted data. At processing block 1210,decoding device 102 decrypts the payload and determines if the block ofdata is a resync block. If not, processing continues at step 1219. Ifthe block of data is a resync block, processing continues at block 1211.

At processing block 1211, decoder 102 checks if key delta tag 810changed. Delta tag 810 indicates if PCX content key has changed. If so,at processing block 1213, decoding device 102 retrieves PCX content key714 from shared buffer 700. At processing block 1215, decoding device102 extracts PCX tag 610 and performs a look-up of the resync block 720within shared buffer 700. Decoding device 102 restores the originalpayload.

Decoding device 102 then decrypts the PCX content key using thepreviously negotiated PCX session key. At processing block 1218, decoder102 reinitializes the decryption cipher using the PCX content key andthe random initialization vector 815.

At processing block 1219, decoder 102 decrypts the payload using thedecryption cipher. At processing block 1220, the decoding device 102decodes the payload of the unencrypted data for further processing (forexample, playback by MPEG decoder).

The protocol specific data may contain copy control information (CCI)which allows the content owners to assign varying levels of priority forwhat can and can't be done with the data. The data may be “copy free”which means there is no restriction to copying the data. The other endof the spectrum is “copy never” which means that as soon as the AKE isnegotiated, a device must render the data immediately. In this scheme, adevice can not make any copies, can not save the data for later use, oranything similar. Thus, when a device receives the data, it is sent tothe consumer, and then the data gets thrown away.

The other two schemes are “copy once” and “copy no more.” If a devicereceives data that is marked as “copy once,” the device may make asingle copy of the data if the user chooses to do so. This scheme allowsrecording for later viewing. When a device receives data that is marked“copy once,” the device may save it, but then once it is saved, when itis retrieved after saving, the device must mark the data as “copy nomore.”

In one embodiment, during transfer of data within system 100, if thedata is unencrypted, the CCI information is susceptible to interceptionand unauthorized change. Thus, if the data is marked “copy never” andthe information is hacked, the data may be pirated within system 100.The CCI information is contained within transmission header 602. Thetransmission header 602 is not encrypted during transfer though system100 and is susceptible to change.

Within system 100, the CCI information is built into the PCX contentkey. The CCI information retrieved from the data stream in transmissionheader 602 is used as part of the seed to generate the key. Thus, bycombining the PCX content key with the control information beforere-encryption, system 100 guarantees that any modification of the CCIinformation in the transmission header 602 will result in incorrectdecryption of the protected data. During decryption of the re-encrypteddata by decoding device 102, the CCI information is extracted from thetransmission header 602 and combined with the PCX content key to createthe decryption key.

The above method may be used to protect any information embedded withinthe transmission header 602. Thus, information such as, for example,copy quality which may indicate the quality of audio a user is allowedto copy, how many times a device is allowed to copy this content, andsimilar information may be protected from change while the data istransferred within system 100.

FIG. 13 is a block diagram of one embodiment for an informationsynchronizing system 1500. Content exchange device 1510 is configured toreceive fixed-size data 1505. Content exchange device 1510 is furtherconfigured to save a portion of the original payload of the fixed-sizedata 1505 in shared memory buffer 1540 and configured to savesynchronization information together with the original portion in sharedmemory buffer 1540. In one embodiment, decryptor 1525 is configured todecrypt fixed-length data 1505 as it is received by content exchangedevice 1510. Negotiator 1515 is configured to embed a tag to theappropriate synch block in shared memory buffer 1540 within a payloadarea of the fixed-size data 1505 to produce replacement data 1530. Inone embodiment, encryptor 1520 is configured to encrypt the payload ofreplacement data 1530 and configured to encrypt the original payloadsaved in shared memory buffer 1540.

Decoding device 1535 is configured to extract the embedded tag fromreplacement data 1530 and to retrieve the original payload andsynchronization information from shared memory buffer 1540 correspondingto replacement data 1530.

In one embodiment, decoding device 1535 is contained within the samedevice as shared memory buffer 1540. In an alternate embodiment,decoding device 1535 is a separate device from the device containingshared memory buffer 1540.

While certain exemplary embodiments have been described and shown in theaccompanying drawings, it is to be understood that these embodiments aremerely illustrative of and not restrictive of the broad invention. Thepresent invention is not limited top the specific constructions andarrangements shown and described, and alternative embodiments willbecome apparent to those skilled in the art to which the presentinvention pertains without departing from the scope of the presentinvention. The scope of the present invention is defined by the appendedclaims rather than the forgoing description. In the appended claims, aphysical embodiment of each recited circuit limitation does notnecessarily include completely separate physical devices from anotherrecited circuit limitation. An embodiment of each circuit may share atleast one element with another circuit.

1. A method comprising: receiving a data stream from a source device, bya sending system, the data stream comprising a sequence of data blocks,wherein each data block comprises a header and a payload; the sendingsystem negotiating with each of at least one application decoder togenerate a session key shared between the sending system and the atleast one application decoder, each session key to encrypt at least adecryption key; for each data block, encrypting a payload by the sendingsystem, the payload corresponding to the each data block, the encryptionusing at least one key; the sending system storing a portion of theencrypted payload to be transmitted later to the application decoder,wherein the stored portion is one of an encrypted portion and anunencrypted portion; the sending system replacing the stored portion ofthe encrypted payload with a tag, the tag identifying the data streamand a source of the data stream; the sending system setting a flag in aheader of the data block corresponding to the encrypted payload, theflag indicating that (a) at least one of said payload is encrypted and(b) said payload includes the tag; and transmitting by the sendingsystem each of the data blocks to an appropriate one of the at least oneapplication decoder.
 2. The method as recited in claim 1, wherein thesending system comprises a protected content exchange (PCX) modulehaving at least one decryptor, a protocol specific registration engine,at least one encryptor, and a negotiator.
 3. The method as recited inclaim 1, wherein each of the at least one application decoders use adifferent session key.
 4. The method as recited in claim 1, wherein thedata stream identifier references an encryption key and the savedportion of the payload.
 5. The method as recited in claim 1, whereineach of the data blocks is transmitted via a first transmission channeland negotiating is via at least one separate second transmissionchannel.
 6. The method as recited in claim 5, wherein negotiating fromsaid sending system to said receiving system, comprises transmitting ofnon-data block information including (a) at least one key selected fromthe group of session keys, encryption keys and decryption keys, (b) theportion of the encrypted payload to be transmitted later from thesending system to said receiving system, and (c) a datum that identifiesa data-stream that includes the data block.
 7. The method as recited inclaim 1, further comprising determining, for each data block, by adevice specific driver, to which of the at least one applicationdecoders the data block should be sent based on a protocol specific tothe data block.
 8. A machine readable medium having instructions thatwhen executed cause the machine to: receive a data stream from a sourcedevice the data stream comprising a sequence of data blocks, whereineach data block comprises a header and a payload; negotiate with each ofat least one application decoder to generate a session key sharedbetween the sending system and the at least one application decoder,each session key to encrypt at least a decryption key; for each datablock, encrypt a payload, the payload corresponding to the each datablock, the encryption using at least one key; store a portion of theencrypted payload to be transmitted later to the application decoder,wherein the stored portion is one of an encrypted portion and anunencrypted portion; replace the stored portion of the encrypted payloadwith a tag, the tag identifying the data stream and a source of the datastream; set a flag in a header of the data block corresponding to theencrypted payload, the flag indicating that (a) at least one of saidpayload is encrypted and (b) said payload includes the tag; and transmiteach of the data blocks to an appropriate one of the at least oneapplication decoder.
 9. The medium as recited in claim 8, wherein themachine comprises a protected content exchange (PCX) module having atleast one decryptor, a protocol specific registration engine, at leastone encryptor, and a negotiator.
 10. The medium as recited in claim 8,wherein each of the at least one application decoders use a differentsession key.
 11. The medium as recited in claim 8, wherein the datastream identifier references an encryption key and the saved portion ofthe payload.
 12. The medium as recited in claim 8, wherein each of thedata blocks is transmitted via a first transmission channel andnegotiating is via at least one separate second transmission channel.13. The medium as recited in claim 12, wherein negotiating from saidmachine to said receiving system, comprises transmitting of non-datablock information including (a) at least one key selected from the groupof session keys, encryption keys and decryption keys, (b) the portion ofthe encrypted payload to be transmitted later from the sending system tosaid receiving system, and (c) a datum that identifies a data-streamthat includes the data block.
 14. The medium as recited in claim 8,further comprising instructions that when executed cause a devicespecific driver to determine, for each data block, to which of the atleast one application decoders the data block should be sent based on aprotocol specific to the data block.
 15. A system for safeguardingprotocol-specific data within a device, comprising: a first transmissionchannel to transmit at least one protocol specific encrypted datastream; at least one protected content exchange (PCX) device configuredto translate the at least one protocol specific encrypted data streaminto a PCX encrypted data stream; and at least one application decoderconfigured to decode the PCX encrypted data stream, the decoded PCX datastream comprising a plurality of data blocks each data block having aheader and a payload, wherein the at least one PCX device comprises: atleast one protocol specific registration engine configured to registerthe at least one application decoder, at least one negotiator configuredto negotiate at least one content decoder key for the at least oneapplication decoder, the negotiator using a second transmission channelto communicate non-data block data between the PCX device and the atleast one application decoder, at least one decryptor configured todecrypt the at least one protocol specific encrypted data stream, atleast one encryptor configured to encrypt at least a portion of thedecrypted data stream using the at least one decoder key to produce atleast one re-encrypted data stream, a payload replacement module toreplace a portion of a payload of the data block with a tag data thatindicates at least one key for the data block in the PCX device, aheader flag setting module that sets a flag in a header of the datablock when the data block includes the tag, and a data-stream sendingmodule that sends a data-stream, the data stream including the datablock, to the at least one application decoder after the header flagsetting module sets the flag and the encryptor encrypts the data streamand the payload replacement module replaces the portion of a payload.16. The system as recited in claim 15, the negotiator further configuredto negotiate with each of at least one application decoder to generate asession key shared between the PCX device and the at least oneapplication decoder, each session key to encrypt at least a contentdecoder key; wherein each of the at least one application decoders use adifferent session key.
 17. The system as recited in claim 16, thenegotiator further configured to negotiate at least one content channelencryption key with at least one protocol specific device, the at leastone protocol specific device to send the at least one protocol specificdata stream, the content channel encryption key to be used by thedecryptor to decrypt the at least one protocol specific encrypted datastream.